A process object is an object in a computer system that describes the structure and behavior of a business process. As such, the process object may include data, logic, and structures. The process object may have data and routines to manipulate the data, as in object-oriented objects, and structures, e.g., database tables, to describe the relationships (or associations) with other process objects, as in relational database objects. In a system, these process objects are generally the core structuring components to encapsulate the functionalities that applications need to implement business processes. Each process object advantageously provides a discrete representation of the structure and behavior of a business process. An application to implement a business process may then advantageously access the appropriate process objects and their data, without having to know the details of the underlying implementation.
Unlike traditional objects, this process object encapsulates the business process' functionality within the object itself (and, in some cases, in other entities referenced by the object), defines relationships between different components and process objects, and provides the basic building block for applications. Whereas the traditional object defines, rather than encapsulates, functionality at a high level by referring to the business modules that provided the functionality. Here, the business modules are the basic building blocks for applications. The traditional object also does not include structural information about the object's relationships. In many cases, the process object has superseded the traditional object in a system.
Since process objects are generally the core structuring components in a system, the process objects should be designed to operate properly for use in the system in order to avoid propagating errors throughout the system. Therefore, it is important to qualitatively and quantitatively evaluate the process objects to ensure they are acceptable for use in the system.
However, known object-oriented evaluation tools are not effective because they provide metrics to measure certain object-oriented aspects of the objects, but not to measure object relationships. Similarly, known relational database evaluation tools are not effective because they provide metrics to measure certain relational aspects of the objects, but not to measure object data and routines. Neither is there any reasonable way to combine these disparate evaluation tools.
Accordingly, there is a need in the art for an effective way to evaluate the data, routines, and relationships of these process objects to determine their acceptability for use.